<html>
<head><meta charset="utf-8"><title>mir cache predecessors · t-compiler/wg-parallel-rustc · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/187679-t-compiler/wg-parallel-rustc/index.html">t-compiler/wg-parallel-rustc</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/187679-t-compiler/wg-parallel-rustc/topic/mir.20cache.20predecessors.html">mir cache predecessors</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="175666654"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187679-t-compiler/wg-parallel-rustc/topic/mir%20cache%20predecessors/near/175666654" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Paul Faria <a href="https://rust-lang.github.io/zulip_archive/stream/187679-t-compiler/wg-parallel-rustc/topic/mir.20cache.20predecessors.html#175666654">(Sep 13 2019 at 21:44)</a>:</h4>
<p>Hi <span class="user-mention" data-user-id="116009">@nikomatsakis</span> , I started reviewing the code for the mir predecessors cache. The notes suggested refactoring over trying to fix the locks. Is there any documented potential ways to move forward, or would that be best figured out here?</p>



<a name="175666878"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187679-t-compiler/wg-parallel-rustc/topic/mir%20cache%20predecessors/near/175666878" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Paul Faria <a href="https://rust-lang.github.io/zulip_archive/stream/187679-t-compiler/wg-parallel-rustc/topic/mir.20cache.20predecessors.html#175666878">(Sep 13 2019 at 21:48)</a>:</h4>
<p>I also wasn't sure if the issues were created yet. I thought I remembered during the meeting (I'll have to rewatch it) that there would be a list of issues created so we could track who was doing what. I tried searching, but all I could find was <a href="https://github.com/rust-lang/rust/issues/63643" target="_blank" title="https://github.com/rust-lang/rust/issues/63643">https://github.com/rust-lang/rust/issues/63643</a>.</p>



<a name="175849976"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187679-t-compiler/wg-parallel-rustc/topic/mir%20cache%20predecessors/near/175849976" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/187679-t-compiler/wg-parallel-rustc/topic/mir.20cache.20predecessors.html#175849976">(Sep 16 2019 at 20:34)</a>:</h4>
<p>I'm not sure what issues were created, <span class="user-mention" data-user-id="116114">@Paul Faria</span>, good question. Anyway re: the predecessors cache, I'm not sure what I would do. The most minimal change would be to use an <code>Arc</code> so that we avoid returning a lock guard, though to my mind that is not ideal.</p>
<p>I'm going to cc <span class="user-mention" data-user-id="124288">@oli</span> and <span class="user-mention" data-user-id="119009">@eddyb</span>, as they might have some ideas. Y'all, the context here is that we were looking at the MIR <code>predecessors</code> function, which currently stores the preds for a block in a kind of ref-cell (or, in parallel mode, a mutex) and returns it. The cache is cleared upon modification and rebuilt lazilly. It all seems kind of complicated and not great -- for example, it is sad to need a lock when MIR is accessed by only one thread at a time when mutating.</p>



<a name="175886558"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187679-t-compiler/wg-parallel-rustc/topic/mir%20cache%20predecessors/near/175886558" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/187679-t-compiler/wg-parallel-rustc/topic/mir.20cache.20predecessors.html#175886558">(Sep 17 2019 at 08:41)</a>:</h4>
<p>This discussion probably belongs in <a class="stream" data-stream-id="189540" href="/#narrow/stream/189540-t-compiler.2Fwg-mir-opt">#t-compiler/wg-mir-opt</a> as the only reason this requires locking at all is because optimizations may change the basic block structure.</p>



<a name="175886640"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187679-t-compiler/wg-parallel-rustc/topic/mir%20cache%20predecessors/near/175886640" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/187679-t-compiler/wg-parallel-rustc/topic/mir.20cache.20predecessors.html#175886640">(Sep 17 2019 at 08:42)</a>:</h4>
<p>We could make everything without interior mutability by adding a MirPass that computes the cache. That pass would have to be added before any passes that need the cache and after the last pass</p>



<a name="175886663"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187679-t-compiler/wg-parallel-rustc/topic/mir%20cache%20predecessors/near/175886663" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/187679-t-compiler/wg-parallel-rustc/topic/mir.20cache.20predecessors.html#175886663">(Sep 17 2019 at 08:43)</a>:</h4>
<p>everyone with immutable access will only ever see a filled cache (because the filling happens after the last pass) and the passes needing access to the cache, have mutable access anyway</p>



<a name="176003909"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187679-t-compiler/wg-parallel-rustc/topic/mir%20cache%20predecessors/near/176003909" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Paul Faria <a href="https://rust-lang.github.io/zulip_archive/stream/187679-t-compiler/wg-parallel-rustc/topic/mir.20cache.20predecessors.html#176003909">(Sep 18 2019 at 13:20)</a>:</h4>
<p>Ok, I'll move the conversation there and link important details back here for cross reference</p>



<a name="176745812"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187679-t-compiler/wg-parallel-rustc/topic/mir%20cache%20predecessors/near/176745812" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Paul Faria <a href="https://rust-lang.github.io/zulip_archive/stream/187679-t-compiler/wg-parallel-rustc/topic/mir.20cache.20predecessors.html#176745812">(Sep 27 2019 at 13:34)</a>:</h4>
<p>Just a small update for those not following the thread in <a class="stream" data-stream-id="189540" href="/#narrow/stream/189540-t-compiler.2Fwg-mir-opt">#t-compiler/wg-mir-opt</a>  : It's very likely we can completely remove interior mutability in this case and not need to worry about any parallel issues :)</p>



<a name="176748727"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/187679-t-compiler/wg-parallel-rustc/topic/mir%20cache%20predecessors/near/176748727" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> mw <a href="https://rust-lang.github.io/zulip_archive/stream/187679-t-compiler/wg-parallel-rustc/topic/mir.20cache.20predecessors.html#176748727">(Sep 27 2019 at 14:06)</a>:</h4>
<p><span aria-label="tada" class="emoji emoji-1f389" role="img" title="tada">:tada:</span></p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>